Multi-metric routing calculations

ABSTRACT

In a Mobile Ad Hoc Network (MANET), multi-metric information is gathered and applied to a cost-based route calculation. In particular, each node gathers resource metrics from neighboring of nodes, along with data rate and reliability information for data links to and from the node. This information is applied to a costing algorithm such as Dykstra&#39; Open Shortest Path First algorithm to obtain routes through the network. This approach may be adapted with suitable modifications to use with unicast traffic or with a multicast forwarding group.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/242,747 filed Sep. 30, 2008, which claims the benefit of thefollowing U.S. Provisional Patent Applications, U.S. App. No. 60/976,730filed on Oct. 1, 2007; U.S. App. No. 60/976,735 filed on Oct. 1, 2007;U.S. App. No. 60/976,740 filed on Oct. 1, 2007; U.S. App. No. 60/976,744filed on Oct. 1, 2007; U.S. App. No. 60/976,747 filed on Oct. 1, 2007;and U.S. App. No. 60/976,748 filed on Oct. 1, 2007. Each of theforegoing applications is incorporated by reference herein in itsentirety:

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH

This invention was made with support of the United States Governmentunder Contract MDA972-01-9-0022. The United States Government may havecertain rights in the invention.

BACKGROUND

This application relates to traffic routing in a mobile ad hoc network,and more particularly to the use of various physical layer and networkmetrics to improve cost-based route calculations. There remains a needfor techniques to route traffic efficiently in the context of a mobilead hoc network where traffic demands and network topologies changefrequently.

SUMMARY

In a Mobile Ad Hoc Network (MANET), multi-metric information is gatheredand applied to a cost-based route calculation. In particular, each nodegathers resource metrics from neighboring of nodes, along with data rateand reliability information for data links to and from the node. Thisinformation is applied to a costing algorithm such as Dykstra' OpenShortest Path First algorithm to obtain routes through the network. Thisapproach may be adapted with suitable modifications to use with unicasttraffic or with a multicast forwarding group.

In one aspect, a method disclosed herein includes: receiving a resourcemetric from each one of a plurality of neighbors of a node, the resourcemetric indicative of network resources needed by the corresponding oneof the plurality of neighbors, thereby providing a data link layerresource metric for a route calculation; determining a data rate for alink to each one of the plurality of neighbors using physical layer datathat characterizes a rate of data selected according to the physicalperformance of a wireless communication channel, thereby providing adata rate metric for the route calculation; determining a reliabilityfor a link to each one of the plurality of neighbors using physicallayer data that characterizes a physical reliability of the wirelesscommunication channel, thereby providing a reliability metric for theroute calculation; and applying the reliability metric, the data ratemetric, and the data link layer bandwidth metric to the routecalculation to calculate a plurality of routes including a route foreach one of a plurality of service levels.

In one aspect a computer program product disclosed herein includescomputer executable code that, when executing on one or more computingdevices, performs the steps of receiving a resource metric from each oneof a plurality of neighbors of a node, the resource metric indicative ofnetwork resources needed by the corresponding one of the plurality ofneighbors, thereby providing a data link layer resource metric for aroute calculation; determining a data rate for a link to each one of theplurality of neighbors using physical layer data that characterizes arate of data selected according to the physical performance of awireless communication channel, thereby providing a data rate metric forthe route calculation; determining a reliability for a link to each oneof the plurality of neighbors using physical layer data thatcharacterizes a physical reliability of the wireless communicationchannel, thereby providing a reliability metric for the routecalculation; and applying the reliability metric, the data rate metric,and the data link layer bandwidth metric to the route calculation tocalculate a plurality of routes including a route for each one of aplurality of service levels. The computer code may further perform thesteps of receiving a data packet at the node, the data packet having aservice level indicator; and routing the data packet according to theroute for the service level.

In one aspect, a device disclosed herein includes a data source thatprovides a plurality of data packets; a memory storing neighborhoodinformation for a plurality of neighboring nodes, the neighborhoodinformation including a plurality of resource metrics indicative ofnetwork resources needed by each one of the plurality of neighboringnodes; a radio that provides an air interface to a mobile ad hoc networkincluding links to a plurality of neighboring nodes; a signal processorthat prepares the plurality of data packets for transmission over theair interface; and a router that calculates routes for at least one ofunicast and multicast traffic using a Dykstra Open Shortest Path Firstalgorithm weighted according to the plurality of resource metrics, andaccording to physical layer data available from the signal processor.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention and the following detailed description of certainembodiments thereof may be understood by reference to the followingfigures wherein:

FIG. 1 is a block diagram of a Mobile Ad Hoc Network (MANET).

FIG. 2 is a block diagram of a MANET having multiple backhaul accesspoints.

FIG. 3 is a block diagram of a node in a MANET.

FIG. 4 is a flow chart of a process for multi-metric routing in a MANET.

DETAILED DESCRIPTION

The following description details certain embodiments of a dynamicsegmentation and reassembly technique for use in packetizing data fortransmission over wireless communication links. By tracking link qualitybased on local metrics and/or information shared among nodes in thenetwork, data can be segmented and reassembled dynamically to providemore efficient use of communication links without requiring moreoverhead in individual packet headers. While the invention is describedbelow in relation to Mobile Ad Hoc Networks, it will be understood thatthe principles of the invention may be suitably applied in anyenvironment where link quality and/or transmission modes varydynamically, and information relating to link quality is available tonodes participating in a network.

So-called “infrastructure” networks employ base stations at fixedlocations to form a substantially fixed network infrastructure. The basestations may enable communication among the wireless devices of thenetwork, between a wireless device and another device on anothernetwork, and so on. This general approach is employed, for example, in802.11 or WiFi networks, as well as in cellular telephony networks. Bycontrast, ad hoc wireless communications networks are formed in an adhoc manner among any number of participating nodes that may periodicallyjoin, leave, or move within the ad hoc network. Although such networksdo not belong to any fixed network infrastructure, they may supportconventional network communications such as point-to-point or broadcastcommunications, and may be adapted for use with any of the InternetProtocols (e.g. IPv4, IPv6) or similar, well-established networkingprotocols.

In general, a Mobile Ad Hoc Network (MANET) is an ad hoc wirelessnetwork in which some (or all) of the participating devices—alsoreferred to herein as “nodes”—are mobile. Thus the topography of a MANETmay change not only as nodes enter and leave the network, but as nodesmove relative to one another within the network. As the network topologychanges, communications routes through the network may also vary interms of availability and in terms of quality. While the invention(s)disclosed herein have broad applicability, they may be particularlyuseful in a MANET environment where the context of continuously changingnode-to-node links poses challenges to, and opportunities for,maintaining traffic flow.

FIG. 1 shows a Mobile Ad Hoc Network (MANET) that may be used with thesystems and methods described herein. In general, a MANET 100 mayinclude subscriber devices 102, access points 104, and backhaul accesspoints 108 (for coupling to a core network 110 such as the Internet),and subscriber devices 110, all generally interconnected as shown inFIG. 1. Without limiting the generality of the foregoing, one or more ofthe subscriber devices 102 may be a stationary device 112 that does notmove within the MANET 100. It will be understood that thedevice-to-device links illustrated in FIG. 1 are for purposes ofillustration only, and in no way are intended to limit the nature ornumber of links between devices in the MANET 100, which may be created,removed, and/or modified over time according to any correspondingprotocols followed by the devices within the MANET 100. In general, thelinks among devices within the MANET 100 are wireless links, althoughwired links may optionally be employed in various locations such asbetween the backhaul access point 108 and the core networks 110. Inorder to maintain the MANET 100, typically one or more protocols areshared among the participating devices to control creation, removal, andmodification of individual data links between devices, and to routetraffic and control information among the devices. The term protocol asused herein generally refers to any and all such rules, procedures,and/or algorithms used in maintaining the MANET 100, unless a specificprotocol is explicitly stated or otherwise clear from the context.

Subscriber devices 102 may include any general purpose nodesparticipating in the MANET 100 according to suitable protocols. It willbe understood that while subscriber devices 102 may include terminalnodes that send or receive data, in a MANET 100 as described hereinsubscriber devices 102 may also suitably be employed as intermediatenodes to route traffic to and from other subscriber devices 102. Thus anad hoc network as described herein is generally extensible, and as newsubscriber devices 102 appear within the MANET 100, they may form a partof the MANET 100 fabric that routes traffic among other nodes. Ingeneral, subscriber devices 102 may include any network or computingdevices that include a wireless interface, network protocol stack(s),and the like adapted to participate in the MANET 100. The InternetProtocol may usefully be employed in subscriber devices 102 within theMANET 100 in order to use well-established addressing schemes and thelike. A subscriber device 102 may include without limitation a cellularphone, personal digital assistant, wireless electronic mail client,laptop computer, palmtop computer, desktop computer, video device,digital camera, electrical instrument, sensor, detector, display, mediaplayer, navigation device, smart phone, a wireless networking card, orany other device that might usefully participate in a network. In someembodiments subscriber devices may include a GPS receiver providing aposition and timing reference. In embodiments, each subscriber device102 may be authenticated and/or authorized before being granted accessto the MANET 100.

Access points 104 may be provided to establish a permanent or otherwisegenerally stable infrastructure to the MANET 100. In one embodiment, theaccess points 104 may employ identical network functionality andprotocol stacks as subscriber devices 102. However, an access point 104may have a number of differences related to their dedicated functionwithin the MANET 100. In one aspect, the access points 104 may have noassociated computing device that originates or consumes network traffic.That is, the access points 104 may simply form a fixed mesh ofparticipants in the MANET 100 and relay traffic among other networkparticipants. An access point 104 may also include a physical connectionto a power infrastructure so that it may be physically installed at alocation and operate autonomously without requiring regular maintenancefor battery changes and the like. In another aspect, access points 104may include some minimal supplemental circuitry related to, e.g., statusand diagnostics, or for receiving software updates and the like. Thismay improve continuity of coverage across a physical region wheresubscriber devices 102 may or may not be present with any regularity,and may ensure that wireless network resources are available in adesired area. In embodiments the access point 104 may be of a size andweight making it suitable for mounting and/or concealment in a varietyof locations including indoor and outdoor locations, and includingmounting on walls, floors, ground, ceilings, roofs, utility poles, andso forth.

Each access point 104 may include or utilize a timing reference such asany of the Network Timing Protocols described in RFC 778, RFC 891, RFC956, RFC 958, RFC 1305, RFC 1361, RFC 1769, RFC 2030, and RFC 4330, allpublished by The Internet Engineering Task Force. Each access point mayalso, or instead, include a GPS receiver providing a position and timingreference. In embodiments the wireless access points 104 may have agreater transmit power and/or a greater antenna gain than mobilesubscriber devices 102, thus providing greater physical coverage thansome other devices within the MANET 100.

The MANET 100 may include one or more backhaul access points 108 thatgenerally operate to connect nodes within the MANET 100 to a corenetwork 110 such as the Internet. On one interface, a backhaul accesspoint 108 may have a wireless radio interface, protocol stack(s) andother components of other nodes within the MANET 100. On anotherinterface, the backhaul access point 108 may provide any suitableinterface to the core network 110. The backhaul access point 108 may,for example, be deployed at a fiber access point or the like thatprovides high-speed data capacity Internet traffic. For example andwithout limitation, the fiber access point may include a Gig-E routersite or an OC-3/12 add-drop multiplexer site. In an embodiment thebackhaul access point 108 may include two Gig-E interfaces for backhaulconnections. It will be understood that any number of a variety ofsuitable interfaces for backhaul connections may be usefully employedwith a backhaul access point 108 as described herein.

A backhaul access point 108 may serve multiple access points 104 withinthe MANET 100, and may distribute network load across those accesspoints 104. Alternatively, a single backhaul access point 108 may servea single access point 104. In some embodiments, the number of accesspoints 104 served by a backhaul access point 108 may relate to theamount of intra-MANET traffic and extra-MANET traffic, the nature anddirection of multicast versus unicast data, and so forth. Thisassociation between backhaul access points 108 and access points 104 maychange from time to time depending on the presence of other subscriberdevices 102 within the area, network conditions, and so forth. In somecases an access point 104 may for a time be associated with more thanone backhaul access point.

The core networks 110 may provide access to network resources outsidethe MANET 100. The core networks 114 may connect disparate,geographically remote and/or local instances of the MANET 100 to form asingle network. The core networks 110 may include any and all forms ofIP networks, including LANs, MANs, WANs, and so on. The core networks110 may also or instead include the public Internet. In otherembodiments the core networks 110 may consist exclusively of a singlezone of administrative control, or a number of zones of administrativecontrol, or some combination of an administrative zone and any of theforegoing.

The stationary device 112 may include any subscriber device 102 that,for whatever reason, does not physically move within the MANET 100. Ingeneral, such fixed physical points within the MANET 100 may provideuseful routing alternatives for traffic that can be exploited for loadbalancing, redundancy, and so forth. This may include, for example, afixed desktop computer within the MANET 100.

Details of various MANET 100 protocols—referred to collectively hereinas the MANET Wireless Protocol (MWP)—are provided below. In general, anyof the nodes above that participate in the MANET 100 according to theMWP may include a hardware platform enabling radio software and firmwareupgrades, which may include for example a dedicated or general purposecomputing device, memory, digital signal processors, radio-frequencycomponents, an antenna, and any other suitable hardware and/or softwaresuitable for implementing the MWP in participating nodes.

In embodiments, any of the foregoing devices, such as one of the accesspoints 104, may also include an adapter for other networks such as anEthernet network adapter or equivalent IP network adapter, router, andthe like, so that non-MANET 100 equipment can participate in the MANET100 through the device. It will also be appreciated that, while aconnection to other core networks 110 is shown, this connection isoptional. A MANET 100 (with or without fixed access points 104) may bemaintained independently without connections to any other networks, andmay be usefully employed for the sole purpose of trafficking data amongsubscriber devices 102.

FIG. 2 is a block diagram of a MANET having multiple backhaul accesspoints. In general, the MANET 100 may include subscriber devices 102(not shown), access points 104, and backhaul access points 108 forconnecting to core networks 110, and an edge router 202 that facilitatesrouting between the MANET 100 and the core networks 110.

The edge router 202 may include any devices or systems for maintainingconnectivity between the MANET 100 and the core networks 110, and mayfurther support or enhance network activity within the MANET 100. Forexample, the edge router 202 may include an industry standard and/orproprietary Address Resolution Protocol server, an application server, aVirtual Private Network server, a Network Address Translation server, afirewall, a Domain Name System server, a Dynamic Host ConfigurationProtocol server, and/or an Operations, Administration, Maintenance andProvisioning server, as well as any combination of the foregoing. Thesevarious components may be integrated into the edge router 202, or may beprovided as separate (physical and/or logical) systems that supportoperation of the edge router 202. These supporting systems may ingeneral support operations such as broadband Internet connectivitywithin the MANET 100 and the like, broadcast communications crossingbetween the MANET 100 and the core networks 110, and so forth, as wellas the use of multiple backhaul access points 108 to efficiently routeinter-MANET traffic among subscriber devices 102.

FIG. 3 is a block diagram of a node in a MANET. The node may be any ofthe devices described above, such as a subscriber device 102, accesspoint 104, or backhaul access point. In general the node 300 may includedata sources 302, a data link 304, a signal processor 306, a radio 308,data queues 310, routing information 312, and neighborhood information314. It will be understood that the following description is general innature, and that numerous arrangements of processing, storage, and radiofrequency hardware may be suitably employed to similar affect. Thisdescription is intended to outline certain operations of a MANET noderelevant to the systems and methods described herein, and in no waylimits the invention to the specific architecture shown in FIG. 3.

The data sources 302 may include any applications or other hardwareand/or software associated with the node 300. This may include, forexample, programs running on a laptop or other portable computingdevice, a web server or client, a multimedia input and/or output sourcessuch as a digital camera or video, and so forth. More generally anydevice, sensor, detector, or the like that might send or receive datamay operate as a data source 302 in the node 300. It will be furtherunderstood that some nodes such as access points 104 may not haveindependent data sources 302, and may function exclusively as MANET 100network elements that relay data among other nodes and/or providenetwork stability as generally described above.

The data link 304 may include hardware and/or software implementing datalink layer functionality such as neighbor management, segmentation andreassembly of data packets, Quality of Service (QoS) management, dataqueue servicing, channel access, adaptive data rates, and any othersuitable data link functions. In general, the data link 304 controlsparticipation of the data sources 302, and more generally the node 300,in a MANET. It will be understood that the data link 304 in FIG. 3 mayimplement any number of lower layer (e.g., physical layer) or higherlayer (e.g., routing, transport, session, presentation, application)protocols from a conventional Open Systems Interconnection (OSI) Model,or any such protocols and related functions may be implemented elsewherewithin the node 300, such as in an IP stack executing on the data source302, or in firmware within the signal processor 306 or radio 308, or inadditional functional blocks not depicted in FIG. 3. For example,routing protocols may be implemented within hardware/software of thedata link 304 in order to ensure that nodes in the MANET 100 shareappropriate routing functions. Thus it will be appreciated that whilethe certain elements discussed herein might suitably be placed withinthe data link layer of a formal protocol stack, the systems and methodsof this disclosure might also or instead be implemented with variationsto a conventional protocol stack, or without any formal protocol stackwhatsoever.

The data link 304 may include a link manager that collects neighborinformation from the data link layer, and may form and maintains theneighborhood information 314 for the node 300. This table may be used toestablish routes to neighbors, and may be updated periodically withinformation from one and two hop neighbors as described further below.The link manager may monitor statistics on all active links for a nodeon a link-by-link basis in order to support link quality calculationsand other functions described herein.

The signal processor 306 may include waveform processing and timingfunctions associated with transceiving data at the node 300. This mayinclude, for example, network timing, time-slot and/or frame-basedwaveform configuration, maintenance of one or more families ofOrthogonal Frequency Division Multiplexing waveform modes (or othertransmit mode waveforms), receiver detection of waveform modes, errorcorrection coding, and so forth. In general, the signal processor 306may be implemented in any suitable combination of digital signalprocessors, field programmable gate arrays, application-specificintegrated circuits, microprocessors, or other general orspecial-purpose computing devices.

In one embodiment, a family of Orthogonal Frequency DivisionMultiplexing (OFDM) waveforms may be employed for adaptive data ratecommunications. The modes of the OFDM waveforms may, for example,include 7.2 MHz Quadrature Phase-Shift Keying (QPSK), 4.8 MHz QPSK, 2.4MHz QPSK, 1.2 MHz QPSK, 1.2 MHz Binary Phase-Shift Keying (BPSK), or thelike. The effective data rate for transmit waveforms may be affected byother parameters such as error correction. In order to facilitateimplementation of an adaptive rate system, the transmit modes may beorganized into an ordered list of monotonically increasing data ratesmatched to correspondingly decreasing signal robustness, thus permittingunique mapping of link quality to transmit mode. In one aspect, theactual waveform mode selected to transmit data on a link may beadaptively selected according to any suitable evaluation of link qualityfor links to neighboring nodes.

The radio 308 in general operates to transmit data from the dataqueue(s) 310, as organized and encoded by the data link 304 and thesignal processor 306 (along with any control information, packet headerinformation, and so forth), over a wireless air interface to other nodesin a MANET, and to perform complementary data reception. The radio 308may include any radio frequency analog circuitry and the like, and maybe coupled to the signal processor 306 which converts data and controlinformation between a digital representation used within the node 300,and an analog representation used in radio frequency communications withother nodes. In embodiments, a low power radio 308 may be employed, suchas where the node 300 is a battery-powered mobile device. In otherembodiments, a high-power radio 308 may be employed, such as where thenode 300 is an access point or backhaul access point connected to afixed power infrastructure. In an embodiment, the radio 308 and signalprocessor 306 provide adaptive data rate coding capable of changingtransmit modes, error correction, and the like according to measuredlink quality.

The data queue(s) 310 may include any data for transmission from thenode 300. This may include, for example, data from the data sources 302,data that is relayed by the node 300 from other nodes in the MANET,and/or control information scheduled for transmission within datapackets from the node 300. The data queue(s) 310 may be organized in anysuitable fashion, and may include a single first-in-first-out queue,multiple queues, prioritized queues, and the like. In one embodiment,the node 300 may include multiple prioritized queues to assist inproviding various service levels, such as for QoS traffic. In general,data in the data queue(s) 310 is delivered according to any suitablequeuing mechanism to the data link 304, signal processor 306, and radio308 for transmission within the MANET.

Routing information 312 such as a routing or forwarding table may beprovided to support routing functions by the node 300. In general, thismay include, for example, a destination address or identifier, a cost ofa path to the destination (using any suitably cost calculation), and anext hop on that path. Other information such as quality of service andother metrics for various routes and links may also be provided for morerefined routing decisions.

Neighborhood information 314 may be maintained in a database, flat file,routing table, or other suitably organized volatile or non-volatilestorage within the node 300. The neighborhood information 314 generallysupports the creation and maintenance of the MANET as well as routingfunctions of each MANET node. Within the MANET, each node may interactwith other nodes to autonomously identify and maintain local networkconnections, shift capacity, dynamically form routes throughout thenetwork, and so on. The routing functions of the node (as supported bythe neighbourhood information 314) may accommodate delay-sensitive (e.g.voice) traffic, delay-tolerant traffic with quality of service (QoS)prioritization, and so on.

The neighborhood information 314 may include an identification ofneighboring nodes along with information relating to those nodes. Thismay include one-hop neighbors (i.e., neighboring nodes in directwireless communication with the node 300), two-hop neighbors (i.e.,neighboring nodes that communicate with the node 300 through only oneother node), or any other nodes or participants within the MANET. In oneaspect, neighborhood information 314 includes link quality informationfor the radio 308, which may be obtained from any combination ofphysical layer and data link data, and may be employed to adapt the datarate of communications according to currently present channelconditions. The neighborhood information may also include QoS data usedto select next hops for QoS data. Other useful information may includebandwidth utilization, node weights, node position (either logical orphysical), and queue latency for each QoS type and/or other prioritytype.

In one aspect, the neighborhood information 314 may be gathered duringperiodic exchanges (such as during control transmissions) withneighboring nodes, which may occur under control of the link manager ofthe data link 304. For example, the node 300 may determine outputbandwidth (i.e., data transmit requirements) for each link that the node300 has with a neighbor, and may transmit this to one-hop neighbors.Similarly, the node 300 may receive output bandwidth from each one-hopneighbor. Using this data, each node 300 may further calculate its owninput bandwidth (i.e., data receive requirements) from each link to aneighboring node, and this information may in turn be exchanged withone-hop neighbors. Following a system-wide exchange with one-hopneighbors, the node 300 (and every other node in the MANET) maycalculate a node weight that represents relative output requirements forthe node 300. For example, the node weight, W, may be calculated as:

$\begin{matrix}{W = \frac{{BW}_{out}}{{BW}_{out} + {BW}_{i\; n}}} & \left\lbrack {{Eq}.\mspace{14mu} 1} \right\rbrack\end{matrix}$

where BW_(out) is the total output or transmit requirements for eachlink of the node 300, and BW_(in) is the total input or receiverequirements for each link of the node 300. Finally, the node 300 maytransmit the node weight to each neighboring node, and may in turnreceive a node weight from each neighboring node. It will be appreciatedthat the node weight, W, may be further processed for use with otherneighborhood information 314, such as by limiting the value according tothe number of bits used for control information, or by providing asupplemental adjustment to the node weight to further refine control ofrouting or other MANET functions. Sharing of information for maintenanceof the neighborhood information 314 may be controlled, for example, bythe data link 304, which may apply any suitable technique to determinewhen to share information with one hop neighbors. In one aspect, thedata link 304 may transmit data whenever a change is detected in theMANET such as an addition or deletion of a node.

In another aspect, for a MANET that has location-aware nodes 300 (e.g.,using Global Positioning System (GPS) data, signal strength data, and soforth), the neighborhood information 314 may include position data inorder to support location-based routing and the like.

Having described a MANET in general terms, the description now turns toa more detailed treatment of multi-metric routing in the MANET.

FIG. 4 is a flow chart of a process for multi-metric routing in a MANET.In general, the process 400 operates to gather multi-metric data at anode in the MANET, and to apply the multi-metric data to routecalculations, and ultimately to routing of packets.

The process 400 may begin 402 with receiving resource metrics fromneighbors as shown in step 404. This may include a wide range of metricsand/or calculation results descriptive of data input and outputrequirements at neighboring nodes, and may span a one hop neighborhood,a two hop neighborhood, or some larger neighborhood. This may includeneighborhood information acquired at a node as generally describedabove. In particular, output bandwidth may be usefully employed as ameasure of data transmission requirements for a node relative to thenode's access to time slots or transmission capacity. Output bandwidthmay be calculated (after an exchange of information with neighboringnodes) as described generally above. The output bandwidth may also bemanipulated for use with the systems described herein. For example, theoutput bandwidth value may represent an actual numerical value (or rangeof values) for the number of packets, or a relative value normalizedaccording to the packet count for each queue. In one embodiment, theoutput bandwidth value may be determined relative to the total outputdata capacity for a node, such as a capacity based upon time slotsallocated for the node to transmit using a weighted fair accesstechnique, an unweighted fair access technique, or any other schedulingand/or access control mechanism employed by the node. Thus the outputbandwidth value may provide a relative indication of queued data tooutput capacity. In one embodiment, a minimum or maximum value may beprovided for the output bandwidth value. In an embodiment, a minimum ormaximum increment size may be provided in order to limit the rate ofchange in the output bandwidth value. Thus for example, the bandwidthoutput may be tuned to rise immediately in response to an increasingqueue depth, but may fall slowly in response to a decreasing queuedepth.

More generally, the output bandwidth value may be tuned, weighted, orotherwise revised or adjusted to achieve a variety of schedulingobjectives. For example, an environment where most nodes are expected tobe downloading large quantities of identical data (e.g., streamingvideo) may be tuned for different performance than an environment whereeach node is expected to regularly source unique data (e.g., voice). Ingeneral, factors that may be accounted for in adjusting a calculation ofoutput bandwidth include latency, throughput, overhead, number ofchannel frequencies, stability of the network, size of the network, andso forth. While these factors do not dictate a particular calculationfor the output bandwidth value under any specific circumstances, they doillustrate the types of design objectives and trade offs that may beaddressed by adjustments to the bandwidth output value calculation, eachof which may serve to skew routing calculation in proportion to existingnetwork traffic and network capacity. It will further be appreciatedthat the output bandwidth value calculation may also take account ofvarying traffic types, such as by weighting higher priority queues moreheavily in the calculation, or by using a multiplier when high prioritydata is present in the queues.

As shown in step 406 data rates may be determined for links toneighboring nodes. Where the MANET employs an adaptive data rate system,the data rate for each link may vary according to the quality of thelink. This value is nominally determined by a transmit waveform modeused on each link. The transmit waveform mode may be selected using anysuitable adaptive data rate technique, and the corresponding nominaldata rate may be adjusted as appropriate for overhead to account forpacket header information, synchronization, and so forth. In one aspect,in order to assist in route cost calculations, a net data rate may bedetermined that reflects actual channel data rates as well as the numberof time slots that a node currently receives for transmission over ashared air interface. Thus for example, a node that has twice as manytransmit time slots as a neighbor may have twice as high an effectiveoutput data rate even where the transmit mode for the node and theneighbor are the same.

As shown in step 408, link reliability may be determined. Any suitablemeasure of link quality may suitably be employed. Reliability may bedetermined, for example, based upon physical layer data for the link, orsome combination of physical layer and data link or network layerinformation. For example, each node may exchange packet countinformation with neighboring nodes providing counts for packets sent andpackets received on each link. This data may be used, for example, toevaluate missed, dropped, or otherwise lost packets for each data linkas described below. Each node may also obtain a Receive Strength SignalIndicator (RSSI) from a channel. This data may be obtained, for example,directly from the radio hardware for the node. It will be understoodthat while an RSSI is a common metric available from radio hardware, anysuitable signal strength indicator may also, or instead, be employed. Alink reliability value may be calculated using any of the above data.For example a ratio of sent-to-received packets may be obtained andweighted according to the RSSI. These values provide a useful metricthat combines the actual, physical signal strength and the actual,observed packet integrity for a link. Other metrics may also, orinstead, be employed, such as a signal-to-noise ratio, an averagesignal-to-noise ratio over a predetermined time interval, a bit-errorrate (prior to any forward error correction), or a simple dropped packetcount. The resulting link quality metric(s) may be usefully employed ina number of manners. In one aspect, the link reliability metric(s) maybe stored and associated with the link for use in subsequent routecalculations.

As shown in step 410, routes may be calculated. Any suitable cost-basedroute calculation may be employed in combination with the neighborhoodresource metrics, data rates, and link reliability metrics describedabove. For example, a Dykstra Shortest Path First algorithm may beemployed using these metrics as costs for each hop in a path. Quality ofService (QoS) may be incorporated into route calculations in a number ofmanners. In one aspect, where each node maintains different queues fordifferent QoS service levels, queue latency or depth may be applied as acost for service-level-specific calculations at each node. In anotheraspect, each service level, traffic type, or priority may haveindependent delivery parameters such as latency, throughput, and thelike. Each parameter may be weighted or otherwise costed within theroute calculation according to the service level. Thus a routecalculation for each service level may result in a different route foreach service level resulting from explicit costing of parametersassociated with the service level, from current traffic as reflected inqueues for various service levels, or from some combination of these orother explicit or implicit service-level-based costs.

By combining physical layer characteristics such as data rates, channelaccess, and link reliability with neighborhood-wide data concerningtraffic patterns and demands at each neighboring node (as captured innode weights or the like, described above), different routes may beobtained for different service levels. While this approach may generallylevel loads within the network, load leveling is further improved bycosting based on node resource metrics so that prospective routes avoidcongested or otherwise impaired nodes within the network.

As shown in step 412, data may be routed according to the route(s)calculated in step 410. In general, this includes receiving a packet,identifying a service level for the packet which may be, for example,contained in the packet header, selecting a route for that servicelevel, and then selecting an outbound link for the packet based upon theroute for that service level. In one aspect, a tie breaking mechanismmay be employed to more evenly distribute traffic over substantiallyequal cost routes. This may include, for example distribution amonglower and higher IP addresses of packet destinations, odd and even IPaddresses of packet destinations, or the like.

The process 400 may then return to step 404 where new route calculationsare initiated with the collection of new resource metrics fromneighbors. It will be understood that numerous additions, deletions, ormodifications to the steps of the process 400 may be made withoutdeparting from the scope of this disclosure. For example, a variety ofmetrics may be employed from the network/data link layers of a protocolstack and from the physical layer, including any of the neighborhoodinformation, link information, or other data described above, eitheralone or in various combinations. It will also be appreciated that theorder of acquiring data may be varied, and may occur asynchronously.Thus physical layer data may be revised with each transmit or receive ofdata or at some other interval and may be averaged across a number oftransactions, while neighborhood information may be updated on someregular interval such as one second, two seconds, or some other intervalconsistent with propagation of one hop or two hop neighborhood datathrough the MANET. Route costs may be calculated at any suitablecorresponding or intermediate interval. In one embodiment, route costsare calculated after neighborhood information has been updated for allneighboring nodes. It will similarly be appreciated that numerouspackets may be routed between updates to routing information. All suchvariations and modifications as would be apparent to one of ordinaryskill in the art are intended to fall within the scope of thisdisclosure.

It will be appreciated that, while the foregoing description may applyto unicast or multicast routing, certain considerations will arise foreach routing type, some details of which are discussed below.

In a unicast routing process, multi-level scoping may be employed toreduce routing update overhead for large networks. In such a process,each node may broadcast two types of control messages: an inter-scopemessage and an intra-scope message. The inter-scope message may bebroadcast every five seconds or some other suitable interval, and mayinclude only one hop neighbors. The intra-scope message may be broadcastat some longer interval, e.g., every fifteen seconds and may include allof the two-hops or more neighbors. Each node may store the topologyinformation provided by the intra/inter scope messages in a topologytable which includes both the inter-scope information and intra-scopeinformation. The topology table may be checked once per second todetermine whether or not there is a change in topology. If a changeoccurs then new routes may be computed using, e.g., the Dykstra ShortestPath First algorithm described above. As a result, the route on which apacket travels may become progressively more accurate as the packetapproaches its destination. In one aspect, a node can export routes intoIETF standard wired Internet routing protocols such as the RoutingInformation Protocol (RIP), the Open Shortest Path First (OSPF)protocol, or the Border Gateway Protocol (BGP) to support routing overmultiple wireless and wired networks.

For multicast routing, a forwarding group may be employed to routemulticast traffic to group members. Group membership may be establishedusing a receiver advertisement scheme. Group membership and multicastroutes may be established and updated by receivers on demand. Withoutleaving current groups, each node may periodically flood a memberadvertisement packet, referred to herein as a Join Request. MultipleJoin Requests may be combined in a single control packet to reduceoverhead. This periodic transmission may refresh membership informationand update route information for corresponding multicast forwardinggroups in view of any node movements. When a node receives a JoinRequest packet, the node may store multicast group identifiers, a sourceidentifier, and a sequence number in a message cache (to detectduplicates). The previous node identifier may be stored as well. TheJoin Request may employ a hop count that is updated (e.g., decremented)on each hop, with an initial Time-To-Live value establishing a scope forthe Join Request. When the Join Request packet reaches a multicastsender, the receiving node may create an entry in a member table thatstores forwarding group information, or update an existing entry toindicate that a previous path is still available. Expired entries may bedeleted from the member table after a predetermined time. In general, insuch a scheme multicast senders do not send control packets. Rather, anode between senders and receivers can construct a forwarding grouptable by extracting information from the transient Join Request(s) inits member cache. In the forwarding group table, fore each multicastgroup identifier and sender identifier, a next node identifier may beset to the previous node identifier field in a Join Request.

No explicit control packets are required to leave a forwarding group.When a multicast receiver stops receiving packets for a particulargroup, that node may automatically stop responding to Internet GroupManagement Protocol (IGMP) or similar protocol queries, which will causea timeout of entries in the node's member cache. This in turn causes thenode to stop sending Join Requests, which will eventually time out themulticast route to that node throughout the forwarding group. Ingeneral, this multicast approach can coexist with any unicast routingprotocol since routes are determined independently. Once established,forwarding groups may be used for multicast route calculations using anyof the route calculation techniques described above.

A wide range of software and hardware platforms may be used to deploythe systems and methods described herein. Generally, the systemcomponents may be realized in hardware, software, or some combination ofthese. The components may be realized in one or more microprocessors,microcontrollers, embedded microcontrollers, programmable digital signalprocessors or other programmable devices, along with internal and/orexternal memory such as read-only memory, programmable read-only memory,electronically erasable programmable read-only memory, random accessmemory, dynamic random access memory, double data rate random accessmemory, Rambus direct random access memory, flash memory, or any othervolatile or non-volatile memory for storing program instructions,program data, and program output or other intermediate or final results.The components may also, or instead, include one or more applicationspecific integrated circuits (ASICs), dedicated semiconductor devices,programmable gate arrays, programmable array logic devices, or any otherdevice that may be configured to process electronic signals.

Any combination of the above circuits and components, whether packageddiscretely, as a chip, as a chip set, or as a die, may be suitablyadapted to use with the systems described herein. It will further beappreciated that the above components may be realized as computerexecutable code created using a structured programming language such asC, an object oriented programming language such as C++, or any otherhigh-level or low-level programming language that may be compiled orinterpreted to run on one of the above devices, as well as heterogeneouscombinations of processors, processor architectures, or combinations ofdifferent hardware and software. Any such combination of hardware andsoftware suitable for use in an ad hoc network as described herein maybe employed without departing from the scope of this disclosure.

Those skilled in the art will recognize, or will be able to ascertainusing no more than routine experimentation, numerous equivalents to thesystems and methods described herein. Such equivalents are considered tofall within the scope of the present invention. Moreover, theembodiments described herein are intended to exemplify the invention andnot to limit it. While the invention is described above in connectionwith certain preferred embodiments, other embodiments may be understoodby those of ordinary skill in the art. All such variations,modifications, extensions, additions, omissions, and the like as wouldbe apparent to one of ordinary skill in the art are intended to fallwithin the scope of this disclosure, which is to be interpreted in thebroadest sense allowable by law.

What is claimed is:
 1. An ad hoc network node comprising: a radio thatprovide an air interface to an ad hoc network including a link to eachone of a plurality of neighbors; a first router within the ad hocnetwork node that routes data according to a Scoped Link State Routing(“SLSR”) protocol that employs multi-level scoping to reduce overhead; asecond router within the ad hoc network node that routes data accordingto a protocol selected from the group consisting of Open Shortest PathFirst, Border Gateway Protocol, and Routing Information Protocol; and asignal processor configure to perform the steps of: receiving a resourcemetric from each one of the plurality of neighbors, the resource metricindicative of network resources needed by the corresponding one of theplurality of neighbors, wherein the resource metric includes a nodeweight representing a ratio of bandwidth required for data in tobandwidth required for data out for a corresponding one of the pluralityof neighbors, thereby providing a data link layer resource metric for aroute calculation; determining a data rate for the link to each one ofthe plurality of neighbors using physical layer data that characterizesa rate of data selected according to the physical performance of awireless communication channel of the radio, thereby providing a datarate metric for the route calculation; determining a reliability for thelink to each one of the plurality of neighbors using physical layer datathat characterizes a physical reliability of the wireless communicationchannel, thereby providing a reliability metric for the routecalculation; applying the reliability metric, the data rate metric, andthe data link layer bandwidth metric to the route calculation tocalculate a plurality of routes within the SLSR protocol, the pluralityof routes including a route for each one of a plurality of servicelevels; and sharing network reachability information between the firstrouter and the second router.
 2. The device of claim 1 wherein thesignal processor is further configured to perform the steps of:receiving a data packet at the node, the data packet having a servicelevel indicator; and routing the data packet according to the route forthe service level.
 3. The device of claim 1 wherein each one of theplurality of service levels imposes different requirements on the routecalculation, whereby two or more of the service levels achieve differentrouting trees through the ad hoc network.
 4. The device of claim 1wherein the route calculation includes a Dykstra Shortest Path Firstalgorithm.
 5. The device of claim 1 wherein the signal processor isfurther configured to perform the step of load balancing network trafficby providing a tie breaking mechanism to distribute traffic among anumber of substantially equal cost ones of the routes.
 6. The device ofclaim 5 wherein the tie breaking mechanism is based upon destinationInternet Protocol addresses.
 7. The device of claim 1 wherein the routecalculation is a unicast route calculation.
 8. The device of claim 1wherein the route calculation is a multicast route calculation.
 9. Thedevice of claim 8 wherein the multicast route calculation employs aforwarding group of nodes responsible for forwarding multicast traffic.10. The device of claim 8 wherein the signal processor is furtherconfigured to perform the step of periodically flooding a memberadvertisement packet from the node to request membership in a multicastforwarding group.
 11. The device of claim 8 wherein the signal processoris further configured to perform the step of receiving a join requestfrom one of the plurality of neighbors and conditionally relaying thejoin request when a hop count for the join request does not exceed apredetermined threshold.